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Outline 


>  MMF:  What’s  different 

>  Demonstration  Models  and  Data 

>  Data  Development  Process 

>  Status 

>  Implications 
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MMF  Demonstration: 

What’s  Different? 


-  Direct  application  of  war  fighter  tasks. 

-  Demonstration  of  network-centric  effects  that  features 

SoS-level  fault  trees 

Degraded  Capability  States  (DCS)  at  both  platform  and  component  levels 

Dynamic  effects  of  vulnerability,  reliability,  repair,  . . . 

Alternative  courses  of  action 


11  Fundamental  Elements:  Seven  Levels,  Four  Operators 


X  Planning 
c=2>  Employment 
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MMF  Data: 

What’s  Different? 


Traditionally 

■  System  developer,  user  and  evaluator  determine  a  Damage  Assessment  List  of  critical  Line- 
Replaceable-Units  (LRU). 


■  A  conclave  is  formed  to  assign  a  weighting  to  each  LRU  representing  the  loss  to  mission 
effectiveness  across  all  scenarios  and  environment  conditions. 


■  Limiting  metrics;  mobility,  firepower,  communications  and  catastrophic. 

■  Developmental  test  information  was  not  incorporated  into  V/L  modeling. 

What’s  NEW 

■  Data  development  is  directly  correlated  to  the  Army  Universal  Task  List  (AUTL),  Joint 
Universal  Task  List  (UJTL)  or  Lead  System  Integrator  tasks. 

■  Expanded  metrics  support  a  robust  system  representation  required  for  a  system  of  systems 
evaluation  and  training. 

■  A  closer  communication  between  the  modeling,  testing  and  soldier  community. 

f 

What’s  missing  is  metric  validation  via  developmental  testing. 
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MTBF,  MTTR, 
MCD;  #platforms, 
#comp/platform 


MMF  Demonstration: 

Models  and  Data 


Event  history  of  comp, 
state  changes 


Fault  Trees  for  each 
platform  type’s 
Degraded  Capability 
States 


Event  history 
of  changes  in 
DCS 


Requirements 


Vignette: 

Mission/ tasks/ standards, 
Threat  force, 

Friendly  force 


Capabilities 


Event  history  of  task 
execution  attempts 
(both  success  and 
failures) 


Human  readable 
text  files,  info  to  feed 
into  viewgraphs 


Human  viewable 
replay  (map,  health  meters) 
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Data  Development  Process: 

Overview 


1.  Determine  platform  engineered  capability  elements  (engineer/design  contractor). 

2.  Perform  criticality  analysis  and  develop  system  fault  trees  (engineer/analyst). 

3.  Determine  semantic  and  design  constraints  (engineer/analyst). 

4.  Develop  the  DCS  partially  ordered  set  (Poset)  given  the  constraints  (analyst). 

5.  Determine  the  appropriate  tasks  typical  for  platform  (AUTL/UJTL). 

6.  Determine  the  required  DCS  for  each  tasks  and  color  code  acceptability  (TRADOC 
System  Manager). 

7.  Bin  the  platform  poset  by  tier  and  acceptability. 


8.  Calculate  the  probability  of  available  capability  at  3  levels  (red,  amber,  green) 
for  each  platform  task  per  threat  (analyst). 


r 


A 


Process  requires  closer  communications  between  the  modeling, 
analysis,  testing,  and  training  communities. 
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Degraded  Capability  States: 

Basic  Elements 


Class-II  UAV 


(3) 


Mobility  (5) 

MO  No  Mobility  Degradation 
Ml*  Reduced  Maximum  Speed 
M2  Reduced  Maneuverability 
M3*  Stop  After  T  Minutes 
M4  Reduced  Acceleration 
M5  Total  Immobilization 

Firepower  (12) 

FO  No  Firepower  Degradation 

FI  Lost  Ability  To  Fire  Buttoned  Up  Main 

F2  Degraded  Delivery  Accuracy  of  Main 

F3  Degraded  Initial  Rate  of  Fire  of  Main 

F4  Degraded  Subsequent  Rate  of  Fire  of  Main 

F5  Degraded  Maximum  Range  Main 

F6  Lost  Reload  Capability 

F7  Total  Loss  of  Firepower  Main 

F8  Lost  Ability  to  Fire  Buttoned  Up  Secondary 

F9  Degraded  Delivery  Accuracy  of  Secondary 

F10  Degraded  Initial  Rate  of  Fire  of  Secondary 

FI  1  Degraded  Subsequent  Rate  of  Fire  of  Secondary 

F12  Total  Loss  of  Firepower  Secondary 


Communication  (8) 

XO  No  Communication  Degradation 
XI  Reduced  Range 

X2*  Lost  Line-of-Sight  (LOS)  Data  (ex.  JTRS) 

X3*  Lost  LOS  Voice 

X4*  Lost  Non-LOS  Data  (ex.  SATCOM) 

X5  Lost  NLOS  Voice 
X6  Lost  Internal  Communications 
X7  Lost  External  Communications 
X8  Lost  All  Communications 

Survivability  (6) 

50  No  Survivability  Degradation 

51  Lost  NBC  Protection 

52  Lost  Ability  to  Deploy  Obscurants 

53  Lost  Silent  Watch  Capability 

54  Lost  Active  Protection  System 

55  Lost  Threat  Warning  Capability 

56  Lost  Fire  Suppression  Capability 

Target  Acquisition  (3) 

AO  No  Acquisition  Degradation 
A1  Lost  Daylight  Sights 
A2  Lost  Night  Sights 
A3  Lost  Range  Finder 


*  assigned  degradation  factor  according  to  the  variation  in  components  affecting  speed  or  bandwidth. 
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Surveillance  (4) 

Z0  No  Surveillance  Degradation 
Z1  Lost  Primary  Sensor 
Z2  Lost  Secondary  Sensor 
Z3  Lost  Tertiary  Sensor 
Z4  Lost  All  Surveillance 

Crew  (7) 

CO  No  Crewmember  Incapacitated 
Cl  Commander  Incapacitated 
C2  Squad  Leader  Incapacitated 
C3  Driver  Incapacitated 
C4  Operator  1  Incapacitated 
C5  Operator  2  Incapacitated 
C6  Gunner  Incapacitated 
C7  Loader  Incapacitated 

Passengers  (1) 

P0  No  Passengers  Incapacitated 
PI  Passengers  Incapacitated 

Other  (3) 

01  Lost  Situational  Awareness 
02  Lost  Unmanned  System  Control 
03  Lost  Automated  C2 

Catastrophic  Loss  (1) 

K0  No  Catastrophic  Loss 
K1  Lost  Every  Capability  ^ 


Data  Development  Process: 

Determine  Engineered  Capabilities 


Category 

Description 

ARV 

(RSV) 

UAV 

C2V 

NLOS-C 

Mobility 

ml 

reduced_maximum_speed 

X 

X 

X 

X 

m2 

reduced_maneuverability 

X 

X 

X 

X 

m3 

stop_after_t_minutes  (leaks) 

X 

X 

X 

X 

m  5 

total_immobilization 

X 

X 

X 

X 

Firepower 

fl 

lost_ability_to_fire_buttoned_up_main 

X 

X 

f2 

degraded_delivery_accuracy_main 

X 

f3 

degraded_initial_rate_of_fire_main 

X 

f4 

degraded_subsequent_rate_of_fire_main 

X 

f7 

total_loss_of_firepower_main 

mg 

mg 

howitzer 

fl  2 

lostsecondaryarmament 

X 

Communications 

x2 

lostexternaldata 

X 

X 

X 

X 

x3 

lost_external_voice 

X 

X 

x6 

lost_internal_comms 

X 

X 

x8 

lost_all_commo 

X 

X 
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Data  Development  Process: 

Criticality  Analysis  and  DCS  Fault  Tree  DevelopntwnF  ""''  “ 


tn4  i  a 

m4  reduced  acceleration  by  .25 

m4  reduced  acceleration  by  .50 

m4  reduced  acceleration  by  .60 

XT 


Series  fault  tree  structure 


mA  reduced  acceleration  by  .60 


Engine 


X 


High  Voltage  Generator 


X 


Fuel  Supply 


Jr 


Series  and  Parallel  fault  tree  structure 


Fuel  Supply 


Fuel  Line  1 


i 

Right  Tank 

Left  Tank 

Fuel  Line  2 

- 1 

t 
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Data  Development  Process: 

Determine  Constraints 


-  SEMANTIC  constraints  imply  loss  by  definition, 
i.e.,  if  x7  then  xl5  x2,  x3,  x4  and  x5. 


-  DESIGN  constraints  imply  loss  of  capability  by  the  engineered  component 
relation. 

i.e.,  if  x2  then  x3 


ID 

COMMUNICATION  CAPABILITY 

No  Communication  Degradation 

xi 

Reduced  Range 

X2 

Lost  Line-of-Sight  (LOS)  Data 

X2 

Lost  LOS  Voice 

X4 

Lost  Non-LOS  Data 

X5 

Lost  NLOS  Voice 

X6 

Lost  Internal  Communications 

X1 

Lost  External  Communications 

XS 

Lost  All  Communications 
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Data  Develop ment  Process: 

Develop  Partially  Ordered  Sets 


Of  the  25  =  32  subsets  of  {mv  m2,  jw3,  m4 ,  jw5},  the  constraint  preclude  all  but  these  16: 

tier  0 


{} 

tier  1 

{Ml 
{M2 
{M3 
{  M4 
tier  2 


} 

} 

} 

} 


{  Ml  M2  } 

{  Ml  M3  } 

{  M2  M3  } 

{  Ml  M4  } 

{  M2  M4  } 

{  M3  M4  } 
tier  3 

{  Ml  M2  M3  } 

{  Ml  M2  M4  } 

{  Ml  M3  M4  } 

{  M2  M3  M4  } 
tier  4 

{  Ml  M2  M3  M4  M5  } 


16  states  in  5  tiers 


The  possible  states 
ordered 
bottom-to-top 
by  set  containment 


How  the  NLOS-C  mobility  states  compare  for  capability. 
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Bata  Development  Process: 

Determine  Appropriate  Tasks 


Battlefield  Operating  System 

Sub-Class 

INTELLIGENCE 

Manned  Ground  System 

Unmanned  Ground  System 

Manned  Air  System 

Unmanned  Air  System 

MANEUVER 

Direct  Fire 

Infantry  Fighting 

Vehicle/ Armored  Personnel 
Carrier 

Air  Attack 

FIRE  SUPPORT 

Indirect  Fire 

Unmanned  Ground  System 

AIR  DEFENSE 

MOBILTY/COUNTERMOBILITY/ 

SURVIVABILITY 

Manned  Ground  System 

COMBAT  SERVICE  SUPPORT 
(CSS) 

Fuel  Truck 

Ammo  Truck 

Air  Utility 

Medical/Evacuation 

Personnel  Carrier 

/I  /I  A  VJTA _ 

V 


Chapter  1  ART  1.0;  The  Intelligence  Battlefield 

Operating  System 


ART  1.3.3  CONDUCT  TACTICAL  RECONNAISSANCE 


ART  1. 3.3.1  CONDUCT  A  ZONE  RECONNAISSANCE 


ART  1.3. 3. 2  CONDUCT  AN  AREA 


3SANCE 


ART  1. 3.3.3  CONDUCT  A\ 


x 


This  is  a  new 


art  i. 3.3.4  conduce  frontier  for  the  V/L 

M&S  community! 

ART  1. 3.3.5  CONDII?  ^  TRi 


Requires  (approval  or)  buy-in  from  the  user  community. 
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Data  Development  Process: 

Platform  Tasks  to  Capability  Matrix*  . - 


r. 


m 


TASKS 

Current  tasks 
determine  which 
states  are  adequate. 


Min  Performing  Task 


MOBILITY  (ART  2.2) 


mO  ml  m2  m3  m4  m5 


02:00-03:40, 

03:51-04:17 


ART  2.2  *LSI  A1 .2  Conduct  Tactical  Maneuver 

ART  2.2 


126 


0.25 


mO  ml  m2  m3  m4  m5 


(ml  +  m2) 


03:41-03:51, 

04:20-10:00 


ART  2.5  LSI  Al.5.2  Occupy  an  Attack/Assault 

Position  ART  2.5.2 


350 


mO  ml  m2  m3  m4  m5 


:o.6s- 


03:41-03:51, 

04:15-04:25 


ART  3.3  *  ART  3 .3 . 1 . 1  Conduct  Surface  to  Surface 

Attack 


20 


0.04 


03:47-03:52, 

04:22-04:27, 

04:38-04:43 


ART  3.3  MTP  06-5-A008  Conduct  Fire  Missions 


15 


0.03 


Total  minutes  working  tasks  for  NLOS-C  in  vignette  =  511 


*  MMF  Demonstration 
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Data  Development  Process:  ktj/tt 

Bin  poset  for  Each  Task  K1HEJL.. 


For  task  ART  2.2  LSI  A1.2  Conduct  Tactical  Maneuver*. 


*  MMF  Demonstration 

15 
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Data  Development  Process: 

Task-based  Fault  Tree  Development 


Conduct  Tactical  Maneuver  -  Code  Red 
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Data  Development  Process: 

Calculate  Probability  of  Degradation 


TASK 

Threat  A 

R 

A 

G 

ART  2.2  Conduct  Tactical  Maneuver 

.11 

.15 

.74 

ART  2.5.2  Occupy  Attack/Assault  Position 

.13 

.14 

.73 

ART  3. 3. 1.1  Conduct  Surface  to  Surface  Attack 

.21 

.15 

.64 

MTP  06-5-A008  Conduct  Fire  Missions 

.21 

.15 

.64 

Mission  Health  Average 

.17 

.15 

.68 

Ballistic  vulnerability, 
as  it  relates  to 
mission  tasks. 


Ballistic  vulnerability, 
as  it  relates  to 


pability.\ 


- Capability 

Threat  A 

R 

A 

G 

Mobility 

.20 

.08 

.72 

Communications 

.01 

.04 

.95 

^  Crew 

.00 

.03 

.97 

Catastrophic 

.04 

N/A 

N/A 
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Data  Development  Status 


>  Battlefield  Operating  Systems  (BOS)  have  been  mapped  to  platform 
subclasses,  individual  platforms  in  those  classes,  and  associated  tasks; 
database  of  this  information  is  under  development. 

>  ARL  will  be  visiting  Combined  Arms  Command  (CAC)  and  the  Futures 
Center  to  foster  collaboration  (BOS  and  AUTL/UJTL  to  platform 
assignment). 

>  There  are  plans  to  collaborate  with  TRADOC  schools. 

>  ARL  is  developing  MMF  data  for  select  Current  Force  systems. 

>  Several  related  M&S  tools  are  under  development  to  improve  input 
development  and  results  analysis. 


/  \ 

The  T&E  community  can  leverage  from  these  activities. 

_ J 
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Implications 


>  AUTL  used  for  MMF  can  be  used  to  support  Operational  Testing,  i.e.,  what  the  system 
is  supposed  to  do. 

>  Information  from  Developmental  Testing  can  be  incorporated  into  V/L  modeling  and 
validate  Degraded  Capability  States. 

>  The  same  V/L  modeling  can  be  used  to  provide  pre-shot  predictions  and  support  post¬ 
shot  analysis  during  LFT&E. 

>  Low  level  tasks  derived  from  an  authoritative  source  such  as  the  AUTL  could  be 
incorporated  into  Force-Level  scenario  development. 

>  The  V/L  data  that  supports  the  Force-level  modeling  could  also  be  based  on  the  same 
AUTL. 


/  A 

System  evaluation  would  have  an  auditable  trail  while 

reducing  inconsistency  and  risk. 

) 
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